\documentclass[a4paper,10pt]{article}
\usepackage[utf8x]{inputenc}
\usepackage[cm]{fullpage}

%opening
\title{Course Diary - Entry \#6\\
475 Advanced Topics in Software Engineering}
\author{Eli Gutin \texttt{eg08}, \\ Michael Kwan \texttt{mk08}, \\ John Wong \texttt{jw808} }

\begin{document}

\maketitle

\section{Three key points from the lecture}

\begin{itemize}
\item{
It is critical to the success of software projects that the communication gap between
business people and developers is reduced. While it is great to have working, efficient and
elegant software, it's of no use if it does not meet the needs of the customer. It is challenging because
non-technical users and IT have different ideas about how to achieve the same goal.
This can often lead to large specification documents being written up which are difficult to follow
exactly and time consuming, both to produce and understand. 

These problems have been addressed in several ways. One is to use UI mockups but this is sometimes
ineffective because clients, during requirements discussion, will focus on trivial aesthetic details. Also UIs rarely capture the complexity of the backend.
}
\item{
Another approach to solving the communication problem is to exploit DSLs (Domain specific languages). In this context they may be
used as a specification language. This language describes a set of scenarios and what the expected outcome is of each. It also automatically validates them. While being executable by a machine, they can also be understood by non-developers. In fact it is beneficial for such users to sit down and write them with programmers. This way everyone involved in the project, including stakeholders, will have access to the most up to date and accurate documentation of the system.  

The main drawback with this approach is that significant effort is required to introduce the DSL specification/testing in the first place and it becomes a maintenance burden to maintain it thereafter.
}
\item{
% --Some tools and techniques you can use--
In order to overcome the difficulties of providing and supporting your own DSL, there are generic frameworks available that can be built upon. However these tools are at a very early stage in their development and may potentially have limitations. Examples that were shown included Cucumber which is popular in the Ruby community and FIT which can be used in Java. 

Large system-wide acceptance tests can be difficult to write and need to take into consideration persistence, concurrency and networking. They are also susceptible to run slowly. One way to overcome this is by using the ports and adapters architecture (as was mentioned a few lectures before). This way you decouple your domain model and low-level details which makes it a lot easier to test the business logic in isolation.
}
\end{itemize}

\section{Related Reading}
We read a paper about GUI acceptance testing by Finsterwalder \\ \texttt{http://ciclamino.dibe.unige.it/xp2001/conference/papers/Chapter26-Finsterwalder.pdf}. 
There we learned of an automated way to test the GUI in an application. Usually the front-end is tested manually since it is difficult to describe in the same language that the application was written that "a context-menu should appear after a right-click", for example. For this reason there are tools that record the interactions of a real user with UI at run-time. These record what events occured and can then replay the actions of the user to verify that the same events occur again. The advantage described in the paper is that  representative test cases are easy to produce (as you don't have to manually code them) however the main drawback is that the these test are quite brittle. since the UI inevitably changes a lot during the life of an application's development. It can therefore be seen that maintaining these GUI tests can become an unnecessary overhead and that they should be used only when they serve as powerful acceptance tests. 
\section{Similar Past Projects}
\subsection{Mike's experience}
As an implementor of libraries during my industrial placement, I found one of the easiest way to capture requirements well was to discuss it in terms of concrete pre-conditions and 
post-conditions. Essentially, FIT allows us to do this from an even higher level view, providing a medium for communication at a non-technical level discussing results and outcomes 
rather than implementation details.

\subsection{Eli's experience}
During the group project, last year, the first thing we did was we created the mockup of the UI for our application. As was told in the lecture, this didn't offer much value as the final product changed considerably.
In retrospect it would have been beneficial to work with vertical/horizontal slices and deliver a working version frequently to ensure we were in sync with our supervisor's goals.
\subsection{John's experience}
As I worked in a software development team during my industrial placement, I initially had to know the software itself before I contributed.
I struggled to understand the specification documents and instructions they offered as I encountered many technical terminologies which I often needed to seek for a description. 
I also discovered some incorrect or out-dated information inside the documents as I explored the software. 

\section{Tutorial Exercise Description}
The exercise aims to extend an existing system which controls the checkout tills in supermarkets.
The extension involved adding a new feature - "three for the price of two deals" into the system.
Firstly, we were required to write acceptance tests with the FIT framework to collect and compare the stakeholders' expectations 
to the actual implementation. This stage required getting approval from tutorial helpers. The next step was to implement 
the fixture code so that the original system fails on the tests because it does not have the extended feature, not because the fixtures are lacking. 
Finally, we needed to extend the system to make it pass the tests.

\section{Main Challenges}
One of the main challenges this week was with the new interaction with our `stakeholders/customers' who were \textit{always} right. The `final' expectation was updated multiple times when the 
customer decided to change his mind. On top of this, we had to filter the requirements which were at times unfeasible. However, we were assured by the customer that our final iteration of 
the receipt is what he wanted despite what the specification said. Using a FIT document allowed concrete communication of our ideas to the customer in a form he could understand easily.

\section{Approaches}
We started by writing a new FIT document containing our initial interpretation of the expected report. We then had this checked by the tutorial helpers and through several iterations of discussions 
with these `stakeholders', we finally settled upon a mutually acceptable format for the receipt.

\begin{center}
  \begin{tabular}{ | l | l | }
  \hline
  Line & Text \\ \hline
  1 & 4 Milk @ 0.50 each = 2.00  \\ \hline
  2 & 2 Cheese @ 1.00 each = 2.00  \\ \hline
  3 & 1 Bread @ 0.75 each = 0.75  \\ \hline
  4 & Total = 4.75  \\ \hline
  5 & Discounted Milk @ 0.50  \\ \hline
  6 & Discounted Milk @ 0.50  \\ \hline
  7 & Discount Total = 1.00  \\ \hline
  8 & Discounted Total = 3.75  \\ \hline 
  \end{tabular}
\end{center}

Once the expectation had been set, we went about implementing the changes by first adding a new column to the product table, called \texttt{Discounted}, which stores whether a product is a deal item. 
We then made modifications to the \texttt{GivenTheFollowingProducts} fixture and the \texttt{Product} constructor such that it instantiated products correctly with the 
\texttt{Discounted} flag. The next step was to change our new fixture, \texttt{PurchasesWithDiscount} appropriately to apply the discount logic as well as alter the other FIT documents to have the 
\texttt{Discounted} column. The main work needed to happen in the \texttt{Checkout} class during \texttt{paymentAccepted}. After the total had been calculated, we needed to 
generate a \texttt{Collection} of discounted items and for \texttt{Collection.size() / 3} number of times, get and remove the lowest priced item which would be discounted. 
The accumulative discount price also needed to be stored in \texttt{BigDecimal} form and updated on the fly for the final two receipt lines. Finally, we needed to add methods to 
\texttt{ReceiptFormatter} which were called for the new lines.

After clarifying with the lecturer, we realised the expected behaviour of the LED display - applying the discount algorithm on what is currently in the system. Hence, we needed to edit \texttt{runningTotal} 
accordingly. Whilst implementing this, we found we were duplicating the discount logic and ended up extracting the methods into a separate class which the \texttt{Checkout} class called out to.

\section{Feedback on the lecture/excercise}
We thought that the lecture was quite remindful and it contained quite useful advice to overcome the difficulties on communicating with people without any technical knowledge. 
It highlighted some important aspects of communication, such as DSL and description using concrete examples. Previously, we had not put these into absolute consideration 
but they are crucial in connecting ideas and concepts to non-technical stakeholders.

The exercise was more interesting than the previous ones as we needed to co-operate with a tutorial helper playing the role of a customer and iteratively receiving feedback from him and refactoring the acceptance tests.

\end{document}
